---title: "Transcrição da Prova Teórica 1 — nome: " disciplina: "Gestão de Projetos de Software" codigo_disciplina: "GPS" avaliacao: "Prova Teórica 1" periodo: "2026-2" data: "2026-10-19" discente: nome: "Gabriel Alvarenga Bastos" matricula: "20243001694" curso: "Engenharia de Computação" turma: "Unidade Timóteo" nota_total: 18.0 nota_maxima: 25.0 legibilidade_percentual: 92 metadados_transcricao: transcritor: "Antigravity Assistant (Visão Computacional)" data_transcricao: "2026-10-19" grau_fidelidade: "Fiel (ipsis litteris), preservando rasuras e omissões" format: html: toc: true theme: cosmo pdf: documentclass: scrartcl papersize: a4 geometry: - margin=20mm --- # Transcrição da Prova Teórica 1 — Gabriel Alvarenga Bastos ## Questão 1 ### 1.1 (1,5) Projeto vs. operação — três características com evidências: Um projeto, pois uma operação se trata de uma medida unitária, (sem necessariamente ter um tempo estimado de realizar) e sem realimentação (ou seja, realiza uma atividade sem preocupação de reavaliar impactos e corrigir posteriormente). Seria correto entender como um conjunto de operações, que se preocupa com qualidade, gestão e controle, sendo então projeto. *(anotação do discente: ignora parênteses)* ### 1.2 (2,0) Duas alternativas de trade-off sem sacrificar qualidade + impacto no Triângulo de Ferro: Predizer o escopo garante estimativas de tempo e custo confiáveis, então reduzir os testes automatizados teria de ser compensado por um aumento de testes unitários, para não ferir a qualidade. Outra abordagem seria reduzir o escopo do que falamos que iríamos mostrar para o professor, ou até pedir para adiar a entrega. ### 1.3 (1,5) Ciclo de vida e justificativa (preditiva, ágil ou híbrida): Híbrida é o mais próximo, mesmo que eu ache justo entender como ágil também. Mesmo que utilizamos metodologias ágeis (Kanban, sprints, tempo estimado com story points), temos uma certa previsão dada por um escopo prévio e, se não fosse por ser uma LLM, poderíamos até prever o escopo completamente, caso fosse só um site por exemplo. *(anotação marginal: 15 semanas ~ 3 meses ~ 7 sprints)* --- ## Questão 2 ### 2.1 (1,5) EAP de dois níveis (substantivos, regra dos 100%, $\ge 3$ pacotes de trabalho): ``` 1. Gestão e abordagens iniciais 1.1 README + Project Charter 1.2 Criar subpastas, pom.xml, .env, .gitignore, issues e marcos 1.3 Avaliar estimativas, tecnologias e duração esforço 2. Interface 2.1 Criar bot no telegram que responde (echo) 2.2 Implementar via terminal uma chamada via OpenRouter de LLM 2.3 Avaliar merge requests e códigos e unir interface + backend 3. Personalizar entradas e entrega 3.1 Propor testes... 3.2 Revisão (QA/QC) 3.3 Entrega ``` ### 2.2 (2,0) Duas issues completas no GitLab: *Issue do scrum master para ele mesmo (meu caso)* **Issue #2: Organização do repositório** **Responsável:** Gabriel A. Bastos - [ ] Levantar IDEs dos devs e adicionar no gitignore, tal qual o arquivo .env e /bin - [ ] Criar pasta lib e src, arquivos de placeholder - [ ] Cadastrar issues dos demais membros e milestones, tomando cuidado com estimativas e prazos. *Justificativa:* Cadastrar atividades previamente para cumprir prazos e, quanto antes melhor, para evitar esgotamento da equipe e longevidade do produto. ### 2.3 (1,5) Milestones vs. Sprints + quando Kanban é mais adequado: Milestones não devem ser substituídas por sprints, mesmo que uma milestone tenha uma sprint, pois a mesma se trata de um marco do projeto/produto a ser desenvolvido, e atrasar sprints deve ser tratado diferente de atrasar marcos inteiros. Kanban sem sprints funcionaria em Milestones menores, mas deve-se ter o cuidado de não deixar cards no Doing eternamente, pois Milestones devem ser respeitadas. --- ## Questão 3 ### 3.1 (1,5) DoD vs. DoR — critérios objetivos e garantia de qualidade: Não, pois caso eu tenho um pipeline CI/CD e, para ter ganho de tempo, eu crio uma brecha omitindo algo, mais besta que seja, minha entrega não está pronta. Testes de segurança são mais críticos ainda, e na ausência dele pode ser que eu tenha uma dor de cabeça muito maior na fase de produção. ### 3.2 (1,5) Classificação dos quatro custos da qualidade (PAF): (a) Avaliação; (b) prevenção; (c) falha externa; (d) falha interna O que corresponde a uma falha externa é o mais custoso, pois teria de trocar o pneu com carro andando, e ainda pode ter custos a nível de equipe, pois faltas não previstas costumam ter prazos arrojados, tirar do ar o que deveria estar no ar, etc. ### 3.3 (2,0) Regra 1-10-100 (custo de correção) aplicada a LLMs: A heurística 1:10:100 vai me dizer que meu gasto de recursos com um projeto ao ter uma falha no planejamento, ter uma falha na implementação (interna) e outra na produção (externa), seguem respectivamente uma progressão geométrica de razão 10. Como a IA pode alucinar e se a API KEY ficar aberto, por erro de segurança básico, por exemplo, precisamos investir no planejamento melhor agora para evitar gastos de recursos futuros. --- ## Questão 4 ### 4.1 (1,5) Risco vs. problema (Cap. 6) + quadrante na matriz P$\times$I e estratégia de resposta: ``` [Espaço para desenho/diagrama da Matriz PxI] Marcado ponto no quadrante Crítico (Alta Probabilidade x Alto Impacto) ``` Um problema, pois riscos normalmente são erros já levados em consideração prévia que tem probabilidade e/ou impacto baixos, e hoje em dia deixar .env aberto em repositórios públicos vai deixar você muito famoso na comunidade dos robôs. ### 4.2 (1,5) Três ações imediatas + uma ação preventiva (defesa em profundidade): Adicionar .env no git ignore (não lembro o resto T_T, sei que fica no histórico de commits do mesmo jeito e eu teria de fazer algo que envolve o CI/CD). Ação preventiva: Revisar git ignore após implementar chamada de API em qualquer código. ### 4.3 (2,0) Risco de entrada modelado (causa, P, I, mitigação, contingência) + mitigação de saída + artefato de documentação: Jailbreak (Entendo como eu manipular o prompt para conseguir algo que ele claramente não quer me dar): causado por manipular a semântica de palavras, podendo ser por tentativa e erro, impactando no não cumprimento de uma regra socrática, como enviar um código completo. Estratégia de mitigação: Limitar caracteres, pois Jailbreak exige uso de demasiadas palavras. Um readme parece melhor, pois limite de caracteres é algo comum e, por vezes, obrigatórios (discordo por exemplo: limitaria por padrão). --- ## Questão 5 ### 5.1 (1,5) Comunicação síncrona vs. assíncrona no GitLab + prática/ritual de registro de decisões: A comunicação síncrona consegue feedback imediatos que a assíncrona não oferece, além de trazer objeções com mais frequência, o que é positivo para tomada de decisões justas ou mais inteligentes. ### 5.2 (1,5) Matriz Poder $\times$ Interesse dos 5 stakeholders, premissas e estratégia de comunicação: ``` [Espaço para desenho/diagrama da Matriz Poder x Interesse] - Manter satisfeito: (1) Alunos - Gerenciar de perto: (2) Professor - Centro/Intermediário: (5) Coordenação do curso - Monitorar: (4) Provedor da API - Manter informado: (3) Equipe de desenvolvimento ``` Uma estratégia de comunicação com o professor viável, de forma síncrona, seriam reuniões presenciais breves na faculdade e, assíncronas, seriam por emails. Ambas atividades periódicas, mas os encontros síncronos feitos de forma marcada pelos assíncronos, em um dia x num horário y que seria bom para ambos. ### 5.3 (2,0) Conflito pedagógico vs. técnico — Thomas-Kilmann (1 escolha justificada + 2 inadequadas): Bem, não tenho esse conhecimento. O que sei é que abdicar de uma escolha de segurança/satisfação por uma de preferência é um erro, visto que aceitar uma exigência do cliente para satisfazê-lo e gerar um problema probabilístico (IA alucinando com mais incidência), pode no fim das contas torná-lo insatisfeito. Portanto, explicar que ele quer algo que pode prejudicá-lo é uma opção.